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Idolos Virtuales 



Los "personajes 
virtuales" son un tema 
ya anejo en el mundo 
de la ciencia ficcion 
del que hay multiples 
ejemplos: la IA de la 
novela «La luna es 
una cruel amante» de 
Heinlein, el personaje 
"Max Headroom" de la 
serie de television, la 
marioneta virtual de 
Johnny Nnemonic... 
Los ejemplos son 
innumerables en el 
campo de la Sci-Fi. 
Ahora bien, ^existen 
ya personas virtuales 
en el mundo real? 




odo depende de lo 

Tque se acepte como 
definicion de "per- 
sona virtual". Es di- 
ficil definir este ter- 
mino, pero parece 
que la idea clasica del mismo es la de 
una representacion fotorealista de una 
criatura virtual residente en uno o varios 



ordenadores. En otras palabras, una per- 
sona virtual es una Inteligencia Artificial 
(IA) que usa un interface 3d para repre- 
sentarse a si misma ante el mundo real. 
Si damos por valida esta definicion, 
las personas virtuales no existen aiin en 
nuestro mundo real. ^Existiran algun 
dia? Si aceptamos los criterios del fa- 
moso fi'sico-matematico Roger Penro- 
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El 17 cumpleanos de Kyoko. 

se, el teorema de Godel demuestra que 
cualquier programa de ordenador esta 
sometido a limitaciones basicas que im- 
posibilitan la aparicion de la inteligen- 
cia. Otros cientificos como John Mc- 
Carthy -creador del lenguaje Lisp- 
opinan que, aiin aceptando este punto, 
algun dia existiran programas capaces de 
superar el test de Turing -conocido test 
ideado por Alan Turing para determinar 
la posible inteligencia de un programa-. 

La opinion del autor de estas lineas 
es que McCarthy tiene razon: algun dia 
existiran programas inteligentes. De to- 
dos modos es curioso constatar que hoy 
en dia ya existen programas no auto- 
conscientes capaces de conseguir resul- 
tados que antes se consideraban solo re- 
ali'zables por personas dotadas de gran 
inteligencia. Este es el caso de Deep 
Blue, por su encuentro ajedrecistico con 
Kasparov, o el de los programas que han 
desarrollado teoremas matematicos. Por 
otro lado, en mi opinion, el test de Tu- 
ring no deberia ser aceptado como vali- 
do para medir la inteligencia de un pro- 
grama por dos razones: la primera 
porque creo que pueden escribirse pro- 
gramas no inteligentes que pasarian el 
test, y la segunda porque hay personas 
que probablemente no lo superarian. 

En fin, ya dejando aparte el intere- 
santisimo pero pantanoso campo de la 
inteligencia artificial, hoy dia ya exis- 
ten actores, presentadores e, incluso, 
idolos virtuales. Estas "criaturas" no 
son, por ahora, mas que marionetas vir- 
tuales manejadas por sus creadores hu- 
manos. Algunas de ellas interactuan en 



tiempo real con el mundo de los seres 
humanos mientras que otras, las mas 
"reales", solo se emplean en la genera- 
tion de escenas o peliculas. Veamos al- 
gunos ejemplos. 



DK-96 

DK-96 o Kyoko Date, como se le 
suele llamar, es la primera estrella vir- 
tual nacida en Japon. Se trata de una 
chica sintetica (pero extremadamente 
realista) creada por la agencia japonesa 
de modelos HoriPro, la cual empleo en 
este proyecto a un grupo de ingenieros 
y disenadores que durante cerca de ano 
y medio trabajaron para dar a luz a 
Kyoko. El web original de HoriPro es- 
ta en japones pero, afortunadamente, 
existe una version traducida al ingles 
de sus paginas. La direction de este 
web ingles es www.dhw.co.jp 

Los pocos datos que conocemos so- 
bre Kyoko han sido extrafdos de diver- 
sos webs dedicados a ella (razon por la 
que pedimos disculpas de antemano, 
por si incurrimos en alguna inexacti- 
tude Parece ser que su cuerpo virtual 
consta de unos 40.000 polfgonos y que 
ha sido elaborado enteramente usando 
tecnicas de modelado 3d en lugar de, 
por ejemplo, escaneres 3d. En cuanto a 
la personalidad de Kyoko. sus creado- 
res han sido tambien muy detallistas: 
Kyoko tiene 17 aflos, grupo sanguineo, 
familia, amigos, aficiones, etc. Ha gra- 
bado varios singles (j j ! !), se le han he- 



cho diversas entre- 
vistas, y es una buena danzarina. Salvo 
por el hecho de que no tiene un cuerpo 
fisico, a Kyoko no le falta ninguna de las 
caracteristicas propias de cualquier idolo 
juvenil. Incluso ctienta con varios clubs 
de fans entre los seres humanos reales. 

Naturalmente, y dado que hoy por 
hoy no existe ninguna IA digna de este 
nombre, la personalidad de Kyoko ha 
sido creada sumando rasgos diversos 
de varias personas reales. Todos sus 
movimientos y su manera de bailar se 
han tornado de una bailarina real, em- 
pleando "motion capture", su voz la ha 
tornado "prestada" de una profesional 
de la radio y sus singles han sido gra- 
bados por una cantante japonesa. Sus 
expresiones faciales, movimientos ocu- 
lares, etc, son (jay!) unicamente mani- 
pulaciones informaticas a las que se 
apoya de vez en cuando con "motion 
capture". Todo esto, sin embargo, se ol- 
vida rapidamente cuando se ve una fo- 
to o una animation de Kyoko, y uno 
acaba viendola como un ser real, tal y 
como sucede con otros personajes de 
fiction particularmente bien esbozados 
por sus creadores. 

Por si aun queda alguien que no lo 
sepa, "motion capture" es una tecnolo- 
gia que permite "capturar" los movi- 
mientos corporales o faciales de los se- 
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Rina preparandose para salir. 




res del mundo real empleando sensores o 

camaras. Estos movimientos se convier- 

ten en datos numericos 3d que pueden 
ser empleados por modelos en 3D. Se- 
giin parece, en el caso de Kyoko, 
esto ha sido cuidado hasta el pun- 
to de hacer coincidir las expre- 
siones faciales con lo hablado 
o cantado por esta chica. 
El pelo de Kyoko es corto, se- 
gun se afirma para ahorrar 
tiempo de proceso y memoria. 
Las iniciales DK vienen de 
"digital kids" (chicos digita- 
les) y los "padres" de esta chi- 
ca esperan que en pocos afios 
la tecnologia avance como pa- 
ra permitir que Kyoko participe 

en Shows televisivos de tiempo real, 

junto a los hermanos que, 

sin duda, la seguiran. 
En fin, para aquellos 

que deseeis information 

adicional, os recomenda- 

mos visitar alguna de las 

direcciones indicadas. Po- 

dreis ofr cantar a Kyoko, 

verla bailar, leer alguna de 

sus entrevistas (su biogra- 

fia -ay- aun no ha sido tra- 

ducida del japones origi- 
nal) o enteraros de algunos 

de sus gustos. Como cu- 

riosidad podemos comen- 



tar que su pelfcula favorita es Toy Story 
y su tipo favorito de hombre, Goku de 
Bola de Dragon. Casi nada. 

Rina 

Muy poco podemos decir de Rina 
Kawazuki, ya que todas las paginas 
que hemos encontrado sobre ella en In- 
ternet estan en Japones. Tan solo cons- 
tatar que el estilo 3d con el que esta 
creado el cuerpo de esta chica es bas- 
tante mas manga y menos realista que 
el de Kyoko. ^Se tratara de otro fdolo 
sintetico quinceanero creado por algu- 
na compafiia japonesa? <<,Sera la obra 
de algun infografista de talento? En fin, 
mientras esperamos las respuestas po- 
demos. al menos, disfrutar de las fotos. 
Lo cierto es que se parece a Kyoko co- 




t,Es Rina otra modelo 
virtual? 

mo una gota de agua a otra. ^Sera su 
hermanita menor? 

La chica de Tomwoof 

A pesar de su inferior nivel de rea- 
lismo no hemos resistido la tentacion 
de incluir aquf a esta chica a la que 
Tomwoof -quiza en serio quiza en bro- 
ma- ha convertido en su candidata al 
estrellato virtual. Encontramos a esta 
chica en una de las paginas de Tomwoof 
junto con una pequena resefia sobre sus 
gustos, edad y ambiciones: "ser la me- 
jor estrella virtual posible". 

Nota del autor 

No hemos encontrado aiin ningiin 
fdolo virtual masculino. (,Sera que todos 
los infografistas del planeta son hom- 
bres? Reclamamos la ayu- 
da de las rendermaniacas. 
No hemos incluido aquf 
personajes de videojuegos 
como Chunli, Ryu (Street 
Fighter) o Lara Croft (Tomb 
Raider) porque son conoci- 
dos por los lectores y por- 
que su nivel de realismo es 
menor. Es indiscutible, sin 
embargo, el hecho de que 
estos personajes son, en 
cierto modo, idolos de po- 
pularidad aiin mayor que la 
de la propia Kyoko Date. 
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Trees, inc: 

Un Ipas para crear arboles con POV 

Las fantasticas 
sentencias de 
programacion de 
la version 3 de 
POV estan 
propiciando la 
aparicion de 
toda una serie 
de "Ipas", como 
bien podriamos 
llamar a estas 
utilidades, para 
POV. Uno de 
estos "Ipas" es 

Trees. inc de Sonya Roberts. Esta utilidad es quiza el mejor camino para 
crear arboles para nuestras pov-escenas. Con Trees. inc podremos generar 
arboles de apariencia realista o alienigena, y controlar con facilidad su 
forma, tamaho, nivel de complejidad, colorido y muchas otras cosas mas 
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En el mimero 6 de 
Rendermania se in- 
cluyo una pequena 
disertacion sobre el 
funcionamiento y 
uso de las pov-fun- 
ciones de usuario o pov-macros (como 
prefiere llamarlas el autor de estas lf- 
neas). Como entonces vimos, una pov- 
macro es, simplemente, un fichero .inc 
que contiene un conjunto de sentencias 
pov. De cara al usuario, las pov-macros 
funcionan exactamente igual que las 
subrutinas de programacion, siendo 
empleadas por lo general para crear ob- 
jetos cuya forma exacta de- 
pendera de los valores que se 
haya dado a las variables de 
la pov-macro. Como recorda- 
ra el lector, el truco consistia 
en dar unos valores determi- 
nados a las variables de la 
pov-macro, en el fichero pov, 
y luego usar una sentencia in- 
clude para "incluir" las sen- 
tencias de la pov-macro. Este 
proceso puede repetirse cuan- 
tas veces se desee obteniendo resulta- 
dos diferentes en funcion de los valores 
que se hayan dado a la pov-macro. 

Mencionamos todo esto porque la 
utilidad Trees. inc de Sonya Roberts 
es una pov-macro. Ast, para cada ar- 
bol que deseemos crear, habra que 
indicar los valores correspondientes 
para las variables y colocar una sen- 
tencia include. 

Notas sobre los manuales 

A partir de la version 2.0 de Trees, 
Sonya decidio escribir un tutorial en 
formato html (y en ingles) para su utili- 
dad. Algiin tiempo despues, un usuario 
realizo una excelente traduction al cas- 




tellano (tambien en formato html) que 
hemos incluido en el CD. Dicha tra- 
duccion, no obstante, esta algo anticua- 
da, ya que se refiere a la version 2.0 de 
Trees. La nueva version de trees, la 3.0, 
incluye un fichero html adicional y pre- 
senta cambios en el apartado "Hojas, 
flores y frutos" con respecto al antiguo 
tutorial. Todo lo demas -la explicacio- 
nes acerca de como se generan los ar- 
boles y el funcionamiento de las varia- 
bles- es practicamente identico en 
ambos tutoriales. Este articulo se ha es- 
crito gracias a la information suminis- 
trada por estos ficheros, la cual ha sido 
contrastada (claro esta) con nuestras 
propias pruebas. 



Los arboles de Sonya 

Los arboles generados con el "Ipas" 
escrito por Sonya Roberts son -como 
ocurre con los creados por otras utili- 
dades semejantes- modelos formados 
por cientos o miles de objetos simples. 
Estos objetos simples son, en su mayor 
parte, conos y esferas. Los conos se 
usan para formar el tronco y las ramas. 
y las esferas se emplean para suavizar 
las uniones entre los conos. Puede pa- 
recer increfble que los arboles que aqui 
veis se obtengan partiendo de formas 
tan simples pero el caso es que es asi. 

Los que os animeis a examinar el fi- 
chero Trees.inc observareis que Sonya 
ha hecho un experto uso de las llama- 
das sentencias de programacion de 
POV (if, while, switch, case, rand y 
otras). Estas sentencias han sido em- 
pleadas para escribir los 5 bucles ani- 
dados que sirven para generar los 5 ni- 
veles de estructura con que cuentan 
todos los arboles que se construyen con 
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trees.inc. Estas estructuras son el tron- 
co, las ramas primarias (las que parten 
del tronco), las secundarias, las tercia- 
rias y las terminales, a las que aqui 11a- 
maremos ramitas. En cuanto a las posi- 
bles hojas, flores y frutos del arbol, solo 
pueden partir de las ramitas de este y el 
numero y distribucion de las mismas de- 
pendent, tal y como sucede con el resto 
de las estructuras del arbol, de los valo- 
res que demos a una serie de variables. 

La pseudoaleatoriedad es 
necesaria 

La forma y aspecto finales de cada 
arbol dependen de una serie de varia- 
bles que Sonya clasifica en tres catego- 
ries: las variables para los generadores 
de numeros aleatorios, las variables 
que controlan la forma y distribucion 
de las estructuras del arbol, y las varia- 
bles que afectan al tamano y las pro- 
porciones del arbol. 

Las variables de la primera catego- 
ria sirven, como ya imaginara el lector, 
para obtener arboles diferentes. Aqui 
sentimos la necesidad de hacer un in- 
ciso en beneficio de aquellos render- 
maniacos que desconozcan lo que es 
un generador de numeros pseudoalea- 
torios. Los lenguajes de programacion 
suelen implementar sentencias que re- 
tornan numeros que parecen tornados 
al azar. Realmente la rutina que consti- 
tuye el generador emplea una formula 
para generar los numeros devueltos, 
con lo cual no puede decirse que estos 
sean aleatorios. Pero, sin embargo, a un 
ser humano le resultara imposible pre- 
decir a priori los valores que devolvera 
el generador. Por otro lado el genera- 
dor necesitara un valor llamado semilla 
como entrada para ser inicializado. 
Despues de dicha initialization, y cada 



vez que sea invocado, el generador nos 
devolvera el siguiente valor "aleatorio" 
que corresponda a la semilla suminis- 
trada; por esto se llama pseudoaleato- 
rios a estos numeros. Lo mas importan- 
te es, como veremos enseguida, que 
una semilla dada produce siempre la 
misma secuencia de valores. ^Para que 
puede sernos util esto? Bien, en info- 
graffa existen bastantes aplicaciones en 
las que es imprescindible el uso de nu- 
meros pseudoaletorios. En el caso de 
trees, por ejemplo, los valores devuel- 
tos por la semilla SD1 se usan para 
controlar el nume- 
ro de ramas y la 
orientation de las 
mismas. Esto sig- 
nifica que bastard 
con cambiar el va- 
lor dado como se- 
milla en la variable 
SD 1 para obtener 
un arbol diferente. 
(Y tambien signi- 
fica que no podre- 
mos predecir si la 
construction del 
arbol nos parecera 
satisfactoria. Si no 
lo es tendremos, 




plear varias semillas al mismo tiempo. 
Dependiendo de cual sea la referencia- 
da (por la sentencia rand), el generador 
nos devolvera un valor u otro. Gracias a 
esto Sonya ha podido emplear tres se- 
millas en Trees: ademas de SD1, que 
controla las divisiones de ramas en el 
arbol, trees usa las variables SD2 y 
SD3. SD2 nos permitira cambiar la dis- 
tribucion aleatoria de las hojas, flores 
y frutos en las ramitas sin alterar la dis- 
tribucion general de las ramas ni el nu- 
mero de las mismas (o sea, lo controla- 
do por SD1). SD3 se emplea en 
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simplemente, que probar con otros va- 
lores diferentes para la semilla). 

En cuanto a la obtencion de la mis- 
ma serie de valores en cada uso de una 
misma semilla, se trata de algo cuyas 
ventajas resultan obvias. Por supuesto, 
no hay ninguna razon para tener dos ar- 
boles identicos en un bosquecillo pero, 
si estamos creando una animation, esta 
caracten'stica resultara indispensable 
para no obtener un arbol distinto en ca- 
da frame de la misma. Como recorda- 
reis el generador de POV permite em- 



algunas cuestiones aleatorias relacio- 
nadas con las hojas, flores y frutos. 

Variables que afectan a la 
distribucion y a la forma 

Aparte de las semillas SD1 y SD2 
existe una serie de variables que nos 
permitiran un control mas "predecible" 
sobre la forma global del arbol. Se trata 
de las variables que controlan los an- 
gulos de division. Este nombre alude a 
los angulos que se formaran en cada eje 
entre una rama dada y el tronco. Para 
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comprender esto hay que saber como 
crea trees las ramas. Inicialmente cada 
rama es creada con la base en el origen 
y extendiendose paralela en el eje Y. 
Seguidamente se rota en el eje X una 
cantidad aleatoria de grados, pero di- 
cha cantidad se mantiene comprendida 
entre los valores dados a MinXDeg y 
MaxXDeg. Podemos dar a estas varia- 
bles el valor que deseemos pero parece 
que lo mejor es dar 1 a MinXDeg y 
poner 30 6 40 en MaxXDeg. 

Despues de esta rotacion en el eje X, 
otra rotacion aleatoria en el eje Y dara 
a la rama la orientation adecuada con 
respecto a la rama padre. De nuevo los 
valores aleatorios devueltos estaran 
comprendidos por los niimeros dados a 
dos variables: MinYDeg y MaxYDeg. 
Si se desea un reparto uniforme de ra- 
mas alrededor del arbol, lo cual es lo 
normal, los valores respectivos para es- 
tas variables deberan ser y 360. Valo- 
res diferentes ocasionaran que las ra- 
mas sean creadas solo en una section 
del tronco (lo cual puede ser util si que- 
remos simular un efecto de viento en el 
arbol). Las variables MinZDeg y 
MaxZDeg realizan la misma funcion 
en el eje Z pero normalmente no son 
necesarias y podemos dejarlas a 0. 

Las tres variables siguientes se em- 
plean para conseguir un interesante 
efecto: lograr que las ramas se vayan 
curvando hacia abajo mas y mas, a me- 
dida que se alejan del tronco. Para con- 



seguir esto, los valores dados a las va- 
riables IncXDeg, IncYDeg y IncZDeg 
se suman a los valores mfnimos y ma- 
ximos de las variables explicadas ante- 
riormente. Si por ejemplo hemos dado 
el valor 5 a IncXDeg, y teniamos los 
valores 30 y 40 en MinXDeg y MaxX- 
Deg, los valores aleatorios devueltos en 
el eje X estaran comprendidos entre 30 
y 40 grados para las ramas primarias 
pero pasaran a oscilar entre 35 y 45 
grados para las ramas secundarias y las 
ramas terciarias se inclinaran entre 40 y 
50 grados. Podemos dar valores negati- 
vos a IncXDeg con lo cual las ramas se 
curvaran hacia arriba. 

Las siguientes variables de este gru- 
po afectan a la frondosidad del arbol. 
Los valores dados a MinSplits y MaxS- 
plits serviran para especificar el nume- 
ro mi'nimo y maximo de ramas que 
pueden partir del tronco o de una rama 
padre. Hay que tener cuidado sobre to- 
do con el valor dado a MaxSplits, ya 
que el numero de objetos del arbol po- 
drfa dispararse. Como nuevamente se 
usa el generador de pseudoaleatoriedad 
nos sera imposible predecir el numero 
total de ramas (a menos que los valo- 
res para ambas variables sean identi- 



cos) pero si podemos saber el numero 
maximo de objetos que tendra el arbol. 
Sonya adjunta el siguiente ejemplo. Pa- 
ra un valor de 4 en MaxSplits, el nume- 
ro maximo de ramitas sera de 

4*4*4*4=256 

(Solo hay 4 multiplicaciones porque 
aunque hay 5 niveles de estructuras-ra- 
ma, el primer nivel es el tronco). 

Otra variable importante es Inc- 
Splits. Al usar Trees, el usuario tendera 
a dar valores relativamente altos a 
MinSplits y MaxSplits para obtener ar- 
boles frondosos. El resultado final, no 
obstante, puede ser insatisfactorio si lo 
que buscamos es conseguir una distri- 
bution mas "real". Como hace notar 
Sonya, los arboles reales tienen por lo 
general mas ramas secundarias en ca- 
da rama primaria que primarias en el 
tronco y mas ramas terciarias en cada 
secundaria que secundarias en cada pri- 
maria. O sea, que la complejidad es- 
tructural de los arboles suele ir crecien- 
do en cada nivel a medida que nos 
alejamos del tronco. Sonya implemen- 
ta la variable IncSplits para simular es- 
to. IncSplits es un multiplicador que 
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afecta a MaxSplits en cada nivel de la 
estructura. Supongase que tenemos un 
valor MaxSplits de 4 y un valor de 
IncSplits de 1.25 (ejemplo dado por 
Sonya). Entonces el maximo numero 
posible de ramas primarias sera de 4 
pero el de ramas secundarias podra ser 
de 5 y el de ramas terciarias de 7. Aquf 
Sonya hace dos recomendaciones: 
jCuidado con el maximo numero posi- 
ble de ramas! Tambien es recomenda- 
ble emplear las variables de incremento 
de grados, ya de lo contrario podria 
ocurrir que todas las ramas se apeloto- 
naran en un mismo volumen espacial. 

Tamario y proporciones 

No es nada recomendable realizar 
operaciones de escalation una vez cons- 
truido el arbol jtiene demasiados obje- 
tos! En lugar de esto daremos el valor 
adecuado a la variable BaseLen, que se 
emplea para determinar el tamano del 
arbol. BaseLen -cuyo valor por defecto 
es 1- es el radio de la base del tronco 



del arbol. Como, 
por defecto, el ar- 
bol tiene siempre 
las mismas propor- 
ciones, cambiando 

esta variable cambiaremos el tamano 
global del arbol. (El tronco del arbol tie- 
ne una altura de unos 1 9 metros). 

Otra variable importante es Lenght- 
Inc que se usa como multiplicador para 
modificar las proporciones del arbol. 
Un valor de 1 da como resultado arbo- 
les compactos y un valor cercano a 2 
nos da arboles "estirados". 

Por ultimo BallJoint controla el ni- 
vel de detalle (o numero de esferas de 
suavizado) del arbol. Con un valor de 
las esferas se desactivan (ahorrando 
tiempo y memoria) y con un valor de 5 
se obtiene el maximo nivel de detalle 
(para camaras muy cercanas al arbol) 

Hojas f lores y frutos 

Los cambios mas importantes que 
trae la version 3.0 de Trees con respec- 





to a su predecesora estan en este apar- 
tado. Ahora el usuario podra elegir en- 
tre una libreria bastante amplia de ob- 
jetos para adornar sus arboles con 
hojas, frutos y ramas. E incluso podra, 
si es precise incluir sus propios objetos 
para que sean usados con este fin por 
lautilidad. 

Los objetos de la libreria son en su 
mayor parte muy sencillos (la naranja 
es una esfera simple, el limon es una 
triple esfera algo alargada, etc.). Esto 
se debe, por supuesto, a que los arboles 
se construyen a base de cientos e inclu- 
so miles de objetos. Si estos objetos no 
fueran lo mas sencillos posible, enton- 
ces el tiempo de render se disparan'a 
(ejem, en realidad ya se dispara). Esto 
hace que la option de incluir objetos 
propios en el arbol no sea demasiado 
util. En teoria seria fantastico crear un 
arbol que tuviese mangababes, coches u 
otros objetos complejos como frutos. En 
la practica, no obstante, el tiempo y las 
limitaciones de ram lo hacen imposible. 

Ahora veamos las variables que in- 
dican a Trees que objetos deben usarse 
como hojas, frutos y ramas en el arbol, 
y cual ha de ser su apariencia. En pri- 
mer lugar tenemos a LeafShape cuyo 
valor designara al objeto de la libreria 
que hard las veces de hoja. Su valor 
puede ir desde a 8. En cuanto a la tex- 
tura que se aplicara a la hoja seleccio- 
nada, sera la indicada por el valor que 
demos a LeafTexture. Despues tene- 
mos a FruitShape, que sera usado de la 
misma manera para indicar al objeto de 
la libreria que servira como fruto. El 
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valor de esta variable puede estar com- 
prendido entre y 5 y el niimero de la 
textura para el fruto se especificara en 
FruitTexture. Finalmente el valor de 
FlowerShape se emplea para indicar a 
Trees el tipo de flor que queremos para 
el arbol y el valor de FlowerTexture se 
usa para indicar la textura correspon- 
diente. Hay 6 posibles (lores y 6 texturas 
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posibles entre las que podremos elegir. 
En todos los casos el valor por de- 
fecto asignado a estas variables es ys 
el valor usado para indicar que va a era- 
plearse un objeto o una textura creada 
por el usuario es de 1. En este ultimo 
caso el usuario tendra que declarar el 
objeto con el nombre que se indique 
entre parentesis en "user-defined" en el 
fichero tutorial.htm, en el apartado co- 
rrespondiente. (Nota: no vamos a dar 
ahora una relation acerca de las formas 



y texturas de la libreria que correspon- 
den a cada valor, ya que Sonya ha in- 
cluido unas escenas para ilustrar esto 
en el fichero ya mencionado). 

Seguidamente hay una serie de va- 
riables que controlan el niimero de ho- 
jas en cada ramita (con LeafNum) y la 
orientacion de las mismas (con Leaf- 
Rosette). Dicha orientacion forma, por 
defecto, una espiral a lo 
largo de la ramita (sola- 
mente las ramitas pueden 
tener hojas, flores y fru- 
tos). Poniendo "True" en 
la variable LeafRandRot 
lograremos una distribu- 
tion mas irregular y alea- 
toria (cambiando el va- 
lor-semilla de SD2). Por 
ultimo podemos lograr 
un bonito efecto de rose- 
ta en las hojas poniendo 
"true" en LeafRosette. 
Tambien habremos de 
especificar que tipo de 
objeto deseamos que ten- 
ga el arbol al final de ca- 
da ramita. Esto se con- 
trola con el valor de Tip. 
Los posibles valores 
asignables a esta variable 
-por defecto el valor es 1- 
son (nada), 1 (hoja), 2 (fruto) y 3 
(flor). Con respecto a esto puede suce- 
der que nos parezca un poco irreal que 
todas las ramitas tengan un objeto en 
su extremo (aunque seria practicamen- 
te imposible asegurarlo en un arbol me- 
dianamente frondoso). 

Para indicar a Trees el porcentaje de 
ramitas que tendran un objeto en su ex- 
tremo usaremos la variable TipPercent, 
dandole un valor oscilante entre y 1. 
Ademas podemos emplear la variable 
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TipOther de manera conjunta con la 
anterior si deseamos que Trees elija 
entre dos objetos a colocar al final de 
la ramita. Para ello indicaremos en Ti- 
pOther el niimero del segundo objeto 
y TipPercent indicara el porcentaje de 
empleo de uno u otro objeto para las 
ramitas. 

Se nos olvidaba indicar que tambien 
hay que indicar el niimero de textura 
para la corteza del arbol en la variable 
BarkTexture. La libreria dispone de 6 
texturas de corteza (0 a 6) y el valor 
usado por defecto es el 0. 

Texturas propias 

Aunque la posibilidad de crear ho- 
jas, frutos o flores de formas nuevas no 
llegue quiza a ser demasiado utilizada 
por el usuario, si parece muy litil poder 
definir texturas propias para cualquier 
objeto del arbol. Esto puede hacerse de 
dos maneras. La mas evidente es asig- 
nar la textura definida a, por ejemplo, 
el tipo de hoja que vaya a utilizarse, pe- 
ro esto presenta un inconveniente: jto- 
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das las hojas del arbol seran exacta- 
mente iguales! No es que esto sea ne- 
cesariamente malo, sobre todo si el ar- 
bol va a estar a cierta distancia, pero 
podemos lograr un interesante efecto 
empleando otro metodo. 

Defmiremos nuestra propia hoja para 
el arbol sin asignarle ninguna textura y 
luego, despues del #include "trees.inc", 
pondremos la textura para las hojas 
dentro de la declaration del objeto-ar- 
bol. Como ya saben los pov-maniacos, 
de esta manera la textura se aplicara so- 
bre todos aquellos objetos que no ten- 
gan declarada su textura propia, o sea, 
en nuestro caso, sobre las hojas. Natu- 
ralmente si la textura del ejemplo es un 
pigmento simple no habra ninguna di- 
ferencia con respecto al primer meto- 
do, pero si se esta empleando un mapa 
de color los resultados seran similares a 
los que pueden verse en el ejemplo del 
arbol otofial de la foto con el lancero 
medieval. Este ejemplo lo encontrareis 
en lancer.pov y lancerl.pov. 

Usando los arboles de Sonya 

En una de las pruebas realizadas, el 
autor de estas h'neas decidio crear un 
arbol cuyas proporciones fuesen con- 
gruentes con las del lancero medieval 
que se creo para estas paginas hace ya 
tanto tiempo. Como antes se ha dicho, 
la altura por defecto del arbol es de 
unas 19 unidades, que aquf aceptare- 
mos como metros. Por tanto para obte- 
ner una altura de unos 9 metros bastara 
con dar un valor de 0.5 a BaseLen. En 
cuanto al lancero, tenia unas 15 unida- 
des de alto, ya que en las escenas para 
las que fue originalmente exportado ca- 
da metro equivalia a 10 unidades. Por 
esta razon el modelo fue escalado por 
0.10 en todos losejes. 



Por lo que respecta al 
arbol, se empleo un ma- 
pa de color para lograr 
la diversidad de color 
deseada entre las hojas 
-aquf se uso el truco 
descrito en el apartado 
anterior-. La escena se 
renderizo a baja resolu- 
tion pero luego, al lan- 
zarla al tamafio final, se 
advirtieron algunos efectos indeseables. 
En primer lugar, aunque las proporcio- 
nes generales del arbol eran correctas 
con respecto al lancero, no ocurrfa lo 
mismo con los frutos -limones-, los 
cuales por su tamafio mas bien parecfan 
melones. Ademas, el numero de limo- 
nes era excesivo. Por ello, en una segun- 
daprueba, se empleo la variable TipPer- 
cent con un valor de .40. Ademas se 
copio la definition del limon de Sonya 
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para crear un fruto de usuario, pero es- 
calandolo por 0.50 para que las propor- 
ciones fuesen correctas. De todos mo- 
dos, a pesar de esto, los limones fueron 
sustituidos por flores en la escena final, 
i Sencillamente ya habi'a demasiados to- 
nos anaranjados en la escena! 

Aparte de esto, se uso InsSplits con 
1.25 para conseguir el efecto de distri- 
bution "natural" de ramas comentado 
por Sonya y se dio un valor de 8 a 
IncXDeg para que las ramas se fueran 
curvando progresivamente. El valor 
que se ha dejado en SD1 es el que ge- 
nera el arbol mas potable esteticamen- 
te hablando. 

Algunos consejos 

1) Realizad las pruebas iniciales de 
color, tamafio y proporciones del arbol 
con valores bajos para MinSplits y 
MaxSplits. Ahorrareis tiempo. 

2) Si quereis recuperar los valores 
por defecto de Trees para crear un nue- 
vo arbol, incluid el fichero defaults.inc 
que adjunta Sonya. 

3) No escaleis el arbol, usad Base- 
Len. No roteis los arboles, disparareis 
el tiempo de calculo. 

4) No coloqueis varios arboles de- 
masiado cerca unos de otros. Si sus vo- 
liimenes se entrecruzan el tiempo de 
calculo se disparara igualmente. 
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Crear terrenos para 



A menudo es conveniente rematar una escena insertando en 



ella un buen paisaje de fondo. Esto puede ser bastante 
problematic^ ya que, aunque existen muchas utilidades q 
generan "heightfields" para todo tipo de programas de render, 
on tantas las que nos permiten tener algun control sobre la 

■ 

ariencia final del paisaje deseado. Este problema tambien se 
resenta con nuestro querido POV pero, al menos, podemr 
elegir entre bastantes herramientas de generacion de pais; 
ra ayudarnos en este asunto. De entre todas el las quiza « 
Hf-lab de John P. Beale la mas potente y facil de usar. 



ntes de entrar en las 

Aparticularidades de 
Hf-lab nos sentimos 
obligados a hacer 
un inciso para ex- 
plicar algunos con- 
ceptos basicos en beneficio de los pov- 
adeptos mas novatos. Los povmaniacos 
mas veteranos pueden saltarse tranqui- 
lamente el siguiente apartado. 

Los campos de alturas de POV 

El lenguaje escenico de Pov dispone 
de una sentencia llamada height_field 



que permite al usuario generar paisajes 
montanosos. Esta sentencia crea un ob- 
jeto compuesto por una malla de verti- 
ces cuyas "alturas" son determinadas 
por los valores de color de los pixels de 
un bitmap que el usuario selecciona pa- 
ra tal proposito (y que se suministra co- 
mo entrada para la sentencia). Natural- 
mente el fichero con el bitmap no sera 
"pintado" a mano por el usuario (con 
el auxilio de algun programa de dibujo 
2d), sino que sera generado por el mis- 
mo POV o por alguna utilidad de la que 
eche mano el pov-adepto. 



Otra posibilidad, de la que no vamos 
a ocuparnos hoy, consiste en importar 
un objeto con el paisaje ya creado por 
alguna utilidad. En este caso bastan'a 
con "traducir" el objeto al formato de 
POV -si ello es necesario- y escalarlo 
y situarlo debidamente. 

El numero de vertices que tendra el 
objeto que resultara del Height_field 
dependera de la resolution del bitmap 
empleado, ya que cada pixel genera un 
vertice. Esto no afectara, no obstante, 
a las dimensiones del objeto, que ten- 
dra 1 unidad de largo en los ejes X y Z. 
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Los vertices que forman la malla mon- 
tafiosa tendran diversos valores de al- 
tura en Y, dependiendo del pixel co- 
rrespondiente. Estas alturas se 
generaran o bien a partir de un bitmap 
de 8 bits -que nos dara 256 posibles al- 
turas- o bien a partir de una imagen de 
1 6 bits -que nos permitira hasta 65536 
alturas diferentes- Esto quiere decir 
que los formatos de 16 bits son los mas 
adecuados para nuestros propositus, ya 
que nos permitiran obtener una grada- 
cion de alturas mas suave (o sea, 65536 
alturas dentro de un rango de a 1 ). 
El formato de esta sentencia es: 
height_field j 

Tipo_de_fichero "nombre_fichero" 

[ nivel_del_agua ] 

[ smooth ] 

( hierarchy ] 
} 

El formato del fichero empleado pa- 
ra el bitmap puede ser gif, tga, pot, png, 
pgm o ppm. (El formato gif solo per- 
mitira 256 alturas porque su paleta es 
de 8 bits). Los parametros que siguen 
son opcionales. "Nivel_ del_agua es un 
valor flotante que debera estar com- 
prendido entre y 1 y que se refiere 
precisamente a eso: a la altura a la que 
supuestamente se halla el nivel del 
agua en el objeto height_field. Los 
triangulos cuyos vertices tengan altu- 
ras inferiores a la indicada en este para- 
metro no seran visibles; Pov los igno- 
rant. Por ejemplo, un valor de .5 en este 
campo le dice a POV que ignore la mi- 
tad inferior del objeto. 



El siguiente 
parametro afecta 
a la apariencia 
del height_field. 
Como ya hemos 
dicho, este esta 
compuesto por 
triangulos y por 
esta razon la apa- 
riencia final del 
objeto sera face- 
tada. Esto, sin 
embargo, no es 
algo demasiado 
deseable en un 

paisaje montanoso y por ello normal- 
mente incluiremos esta palabra que 
modifica las normales de las caras del 
objeto, a fin de conseguir una apa- 
riencia mas "suavizada". 

En cuanto a "hierarchy", se trata de 
un parametro activado por defecto y 
cuya funcion parece ser la de acelerar 
los tests de intersecciones para los cal- 
culos de visibilidad. 

Una vez creado, el objeto heigh_field 
queda dispuesto de tal modo que su 
esquina inferior izquierda se situa en 
la posicion <0,0,0> y su esquina su- 
perior derecha queda en <1,1,1>. Por 





tanto, sera conveniente centrarlo con 
translate antes de escalarlo para que 
tenga las dimensiones adecuadas pa- 
ra la escena. 

El laboratorio de campos de 
alturas 

Sin duda, los lectores mas veteranos 
ya conoceran el truco que puede em- 
plearse con POV para generar height- 
fields sin recurrir a utilidades externas, 
un truco que ya hemos mencionado en 
ocasiones precedentes. Este truco pre- 
senta, como tantos otros metodos, el 
problema de que la forma final del 
heightfield es poco previsible. Pero, 
afortunadamente, Hf-lab -la utilidad 
que adjuntamos en el CD- podra ayu- 
darnos en esto. 

Hf-lab es una utilidad que puede ge- 
nerar, manipular y visualizar height- 
fields. Se trata, de hecho, de un conjunto 
de utilidades que han sido agrupadas por 
Beale. (Entre ellas esta Gforge, creada 
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por el propio Beale, y que 
quiza sea conocida por al- 
gunos pov-maniacos). El 
funcionamiento de Hf-lab 
se asemeja en gran medi- 
da al de un sistema opera- 
tivo de factura antigua co- 
mo CP/M o MS-Dos 
puesto que trabaja me- 
diante comandos escritos. 
Estos comandos pue- 
den ser clasificados en 
varias categon'as dife- 
rentes. Por un lado tenemos los coman- 
dos de generation del heightfield, lue- 
go estan los operadores y los comandos 
de manipulation, hay un comando para 
la visualization del bitmap que corres- 
ponde al heightfield en curso y otros 
para visualizar y manipular al objeto 3d 
resultante, tenemos tambien ordenes 
para manipular el stack y otras de cla- 
sificacion menos clara. 

Instalando Hf-lab 

Debemos descomprimir el fichero zip 
con la orden "Pkunzip -d hf-lab.zip", la 
cual creara un subdirectorio llamado 
hf-lab, dentro del cual se descomprimi- 
ra la utilidad. Aparte de algunos fiche- 
ros de texto y del propio programa ve- 
remos un fichero llamado hf-lab.hlp 
que es la ayuda en linea del programa. 
Es conveniente instalar dicha ayuda 
puesto que en ella se explican todos los 
comandos aceptados por Hf-lab (y que 
no se explican en los otros ficheros de 
texto). Para instalar dicha ayuda edita- 
remos nuestro fichero autoexec.bat y 
colocaremos una linea de la forma: 

SET HFLHELP=pafh_a_hf-lab.hlp 

es decir, que si el programa se en- 




cuentra en c:\pov301\tools\hf-lab debe- 
remos escribir 

SET HFLHELP=c:/pov301/tools/ 

hf-lab/hf-lab.hlp 

Una vez dentro del programa podre- 
mos acceder a esta ayuda en linea te- 
cleando help o "?" para ver una lista de 
las ordenes permitidas por la utilidad o 
usando "help comando" para obtener 
information especifica de una orden u 
operador determinado. 



La filosofia de 
trabajo de Hf-lab 

Gran parte de la filoso- 
fia de Hf-lab se basa en 
la idea de la pila o stack. 
Una idea con la que es- 
taran muy familiariza- 
dos los programadores 
de Ensamblador y los de 
Forth. Para explicar co- 
mo funciona se suele re- 
currir a la imagen de la 
ti'pica pila de platos del 
fregadero: el primer plato que se colo- 
co en la pila esta ahora en el fondo de 
la misma y el ultimo ha quedado en la 
cima y sera, por consiguiente, el pri- 
mero en ser fregado. Lo mismo sucede 
con la pila de Hf-lab la cual tiene, ini- 
cialmente, un h'mite de 4 heightfields. 
El sistema de trabajo habitual consiste 
en generar uno o mas heightfields con 
la orden Gforge y realizar diversas ma- 
nipulaciones en ellos (como anadirles 
crateres) para despues visualizar los re- 
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sultados con View. Pasaremos de uno a 
otro heightfield manipulando la pila y 
por ultimo, cuando el resultado de 
nuestro trabajo sea satisfactorio, podre- 
mos grabar el bitmap resultante, que 
luego podra ser empleado desde POV 
en alguna sentencia height_field. 

El comando gforge 

El comando de generation mas im- 
portante es Gforge y su formato es: 

Gforge <n-puntos> <aspereza> 

Esta orden crea una malla (o array) 
cuadrada de n-pixels por lado. La apa- 
riencia de la superficie es controlada por 
el parametro "aspereza" cuyo valor por 
defecto es de 2. 1 ; un valor que da una 
apariencia fragmentada. Si reducimos es- 
te valor, la apariencia sera algo mas suave. 

Hay que tener cuidado con el tamano 
de los arrays ya que el gasto de memo- 
ria va incrementandose a medida que 
crece la dimension del array. Podemos 
realizar pruebas validas con un tamano 
de 256 puntos y luego emplear valores 
de 512 puntos o incluso mas. 

Nota: Debido a la forma en que se ha- 
cen los calculos, Hf-lab necesita 8 bytes 
por pixel durante el proceso de genera- 
cion. jEsto significa que generar una 
malla de 1000*1000 vertices requerira 
8 megabytes! Por otro lado parece ser 
que hay un bug perdido en la programa- 
cion de Hf-lab. Dicho bug produce una 
fragmentation de memoria Ram similar 
a la que sucede con el tiempo en los dis- 
cos duros. Asi, a medida que aumenta 



el niimero de operaciones realizadas, el 
programa ira desperdiciando mas y mas 
memoria hasta que aparezca el temido 
mensaje de "out of memory". La unica 
solution que hay para esto es, por aho- 
ra, salir del programa y volver a entrar. 

Cada vez que creamos un height- 
field, la nueva malla pasara a quedar en 
la cima de la pila, donde podra ser mani- 
pulada y visualizada usando los coman- 
dos oportunos -los heightfields anterio- 
res seran desplazados hacia abajo en la 
pila- Los comandos "de trabajo" afec- 
tan siempre al elemento que se halle en la 
cima del stack con lo cual, para trabajar 
sobre otro heightfield, tendremos primero 
que colocarlo en la cima de la pila, lo que 
llevaremos a cabo empleando alguna de 
las sentencias de manipulation de la pila 
(como "rot", que hace rotar los elementos 
de la pila, o como "swap" que intercam- 
bia el primer y el segundo elemento). 

Otro dato a recordar es que cada vez 
que se imparte una orden gforge, la ma- 
lla que se producira sera diferente pues- 
to que el programa emplea un genera- 
dor de niimeros pseudoaleatorios con 
este fin. Sin embargo podremos generar 
de nuevo una malla anterior que nos ha- 
ya gustado si reseteamos el generador 
suministrandole la misma semilla que 
dimos para la anterior. Podemos hacer 
estoescribiendo... 

seed valor_de_semilla 

En la practica es conveniente escribir 
un valor de semilla antes de cada orden 
gforge, por si se produce un error o 



queremos recrear parcialmente el desa- 
rrollo de un experimento. 

Una sesion de trabajo tipica 

Ahora comencemos la sesion de tra- 
bajo. Empezaremos por crear dos height- 
fields de distintas resoluciones: el prime- 
ro con 128 pixels y el segundo con 256 
(gforge 128 y gforge 256). Ahora escri- 
bid "list". Esta ultima orden listara en 
pantalla los datos de los heightfields 
guardados en el stack. La primera lfnea 
de datos corresponde a la cima de la pila 
que, como vereis, esti ocupada por el ul- 
timo heightfield creado (el de 256 pi- 
xels). Seguidamente teclead "view" para 
generar una vista tridimensional de este 
heightfield. El programa dispone de di- 
versas calidades de visualization pero te- 
niendo en cuenta el poco tiempo que 
precisa el render con la calidad maxima, 
vale la pena dejar activada esta ultima. 
Una vez en el modo "view" podremos 
impartir diversas ordenes particulates 
para este modo. Para ello esperaremos a 
que el render concluya y entonces tecle- 
aremos la orden y su parametro (si lo 
hay) seguida de return. Asi, para regre- 
sar al modo normal de texto, tecleare- 
mos "quit" seguido de return. Otras or- 
denes validas desde el modo "view" son 
"S modo_de_sombreado" (con valores 
de a 3), "G modo_grafico" (que admi- 
te 0=320*200, 1=640*480, 2=800*600 
y 3=1024*768), y "Tn". Esta ultima or- 
den parece generar un "tileado" a partir 
de la malla initial, o al menos eso es lo 
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Zedge permite alisar los bordes. 



que se aprecia desde el modo 3d 
(tl=activarel tile, tO=desactivarlo). En 
el modo de visualization 2d, sin em- 
bargo, (orden show) veremos que el 
bitmap no ha cambiado en nada (£?). 

Ahora vamos a hacer algunos expe- 
rimentos con la malla pero antes sera 
conveniente preservarla ya que Hf-lab 
no dispone de undo. Regresad al modo 
2d y pulsad "dup". Despues ordenad un 
listado ("list"). Como vereis ha apare- 
cido una nueva malla de identicas ca- 
racten'sticas a la de la cima. 
Ahora realizaremos algunos 
experimentos. Primero pulsad 
"* 2". Esta operation multi- 
plica por 2 la altura de todos 
los puntos de la malla. Hf-lab 
nos permite emplear varios 
operadores como +, -, *, / y 
Pow, cuyo uso afectara a ca- 
da vertice del array. Si el re- 
sultado de la operation no 
nos ha convencido demasia- 
do podremos hacer que el 
heightfield vuelva a su estado 
anterior con una division o 
podremos eliminar el heightfield con la 
orden "pop", la cual ejerce sobre el 
stack el efecto contrario al que produce 
la inclusion de una nueva malla. Con 
"pop", todos los elementos de la pila a 
partir del segundo se desplazan hacia 
arriba con lo que el segundo elemento 
pasara a ocupar la cima, el tercero pa- 
sara a la segunda position, etc. El pri- 
mer elemento es, claro esta, el situado 
en la cima de la pila. 



Ahora vamos a crear un paisaje con 
crateres. Para ello contamos con el co- 
mando crater cuyo formato es... 

Crater numero escala_de_profundi- 
dad escala_de_radio distancia 

El primer parametro indica el nume- 
ro de crateres que van a tratarse. Los si- 
guientes se refieren a la profundidad y 
al radio de los crateres (pero el autor de 
estas h'neas confiesa que aiin no com- 
prende demasiado bien el funciona- 
miento de estos parametros. En la ayu- 
da se indica que estos valores son 
relativos a la normal <,y?). En cuanto a 
"distancia" afecta al numero total de 
crateres que se generaran en el height- 
field. El valor por defecto para este pa- 
rametro es 1 pero parece mas conve- 




niente dejarlo en 5 6 4 para obtener 
mas crateres. Usaremos la sentencia, 
examinaremos el resultado final y -si 
nos parece adecuado- grabaremos 
nuestro trabajo escribiendo, por ejem- 
plo, "save crateres. tga". Esto es todo lo 
que debemos hacer para crear un bit- 
map utilizable desde POV. 

Ahora veamos otros comandos inte- 
resantes de Hf-lab. 



Con "Floor altura" el programa ha- 
rd que todas los vertices con alturas 
inferiores a la especificada por el pa- 
rametro tomen la altura de dicho pa- 
rametro. El efecto visual sera el de 
crear un piano que Simula el nivel del 
agua en la altura indicada por el para- 
metro que sigue al comando. Esto 
puede sernos util para hacernos una 
idea del aspecto que presentara el pai- 
saje desde POV, si anadimos al height- 
field un piano para simular un mar o 
un lago a esa altura. 

Otro comando del mismo estilo es 
"Ceil altura", el cual hace lo mismo 
que el anterior pero igualando los ver- 
tices cuyas alturas exceden la indicada 
por ceil. Esto ultimo puede sernos util 
para crear una planicie en 
una montana (y colocar algo 
sobre ella, claro). 

Notas del autor 

Todas las imagenes del arti- 
culo nan sido generadas des- 
de POV a partir de las tgas 
creadas con Hf-lab. 
Cada escena ha sido el resul- 
tado de un comando aplicado 
sobre el mismo heightfield 
initial. Por cierto, tomad nota 
de que hay que escalar el 
heightfield en Y. De lo con- 
trario la imagen que nos dara POV no 
se parecera a la previsualizacion de Hf- 
lab. Miradel .pov. 

Tan solo hemos comentado algunas 
de las ordenes que permite Hf-lab. El 
programa tiene comandos con los que 
podremos crear picos, simular la ero- 
sion, distorsionar el bitmap de varias 
maneras, combinar dos heightfields pa- 
ra producir un tercero, etc. Asi que ya 
sabeis: [Gforge, gforge y gforge! 
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Nota importante. Podeis remitirnos vuestros trabajos o consultas, bien pur carta a la direction que 
figura en la segunda pdgina de Pcmania, o via e-mail a rendermania.pcmania@hobbypress.es 



El certamen 

de Rendermania 



Hoy, aparte del ya habitual 
carrusel de imageries 
enviadas cada mes por los 
lectores, vamos a 
presentar una propuesta 
dirigida a todos los 
rendermaniacos. Esta 
propuesta esta basada en 
el exito que tuvo la idea, 
inicialmente concebida 
como una broma, de crear 
una batalla virtual entre 
humanos y orcos utilizando 
modelos enviados por los 
lectores. Esta propuesta 
esta basada en vuestras 
propias sugerencias. 



Oscar Alvarez Diaz ya aparecio en estas paginas en el numero 5 con un pov- 
soldado inspirado en Star Wars. Oscar definio diversas posturas para su soldado y 
hoy ataca de nuevo con una magnffica escena donde un bunker imperial defendi- 
do por sus mejores tropas esta siendo masacrado por un... <,ataque rebelde? Podeis 
encontrar los detalles de esta obra en la carta de Oscar, en el foro. Estoy de acuer- 
do contigo en lo que afirmas sobre el manual de POV; muchas veces se echan en 
falta explicaciones adicionales de algunos comandos y estas lagunas nos obligan 
a hacer muchas pruebas adicionales. Por lo que respecta a la niebla creo que tus 
interpretaciones de los comandos para la niebla superficial son correctas, pero no 
estoy seguro de que sea posible hacer el tipo de humo que pretendfas. 

En cuanto a lo que dices sobre la generacion de paisajes de fondo con POV, es- 
toy parcialmente de acuerdo contigo: no es un asunto facil (pero si factible). (.Que 
opinas de las dos utilidades "paisajfsticas" que ineluimos hoy en el CD? Los ar- 
boles de Sonya se crean... jcon sentencias de POV! (aprendetelas ya). Tomo nota 
de tu sugerencia para dedicar un artfculo a la generacion de paisajes. Desde mi 
punto de vista el peor problema es la memoria (los arboles de Sonya o los height- 
fields ocupan lo suyo) pero incluso para esto existen soluciones que comentare- 
mos en proximos numeros. 
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Francisco Javier Diaz Blanco nos envfa una iraagen 
creada con 3D Studio, programa con el cual ha tenido 
dificultades de aprendizaje. <,Y por que -pregunta ob- 
via- no te compraste un buen libro sobre este programa? 
Sera dificil que alguien pueda explicarte en pocas pala- 
bras el funcionamiento del Keyframer ya que, si echas 
un vistazo en algiin libro dedicado a 3D Studio, compro- 
baras que la description del funcionamiento de este mo- 
dulo suele requerir capitulos enteros. 

En cuanto a mi opinion sobre tu imagen, te dire que 
me parece excelente teniendo en cuenta el metodo de 
aprendizaje que has seguido. Lo unico que se te puede 
criticar, siendo muy puntillosos, es que faltan los carac- 
teres en el teclado y que la aplicacion de la textura de 
madera aparece "corrida" sobre la mesa; hubieras debido 
dividir la aplicacion. 



Poco es lo que sabemos sobre esta imagen enviada por el 
grupo Epsilon, salvo que forma parte de un proyecto 11a- 
mado WildRape. Este grupo solicita correspondencia so- 
bre infografia y programacion y nos adjunta su direction en 
el universo real que es: 

Epsilon 

P° Bera-Bera 57, 1° D 20009 San Sebastian Guipuzcoa 

Y su direction e-mail en el ciberespacio: 

epsilon 1 @ arrakis.es 





Jorge Albericio nos envfa sus primeras 
pov-escenas: un templo griego y una casa. ^Y 
pides critica y encima constructiva? Pues 
bien, en la escena de la casa lo primero que 
llama la atencion son las proporciones del 
conjunto: los bancos parecen desproporciona- 
damente grandes en relation a la casa. Otro 
detalle que no convence demasiado es la tex- 
tura que has empleado para puertas y venta- 
nas. Por otro lado tu obra esta muy bien para 
tratarse de una opera prima, aunque aun es 
muy pronto para saber si vas a tener futuro en 
este campo o no. Eso dependera del tiempo y 
ganas que pienses invertir y por ello (teniendo 
tambien en cuenta lo que ya hay en el merca- 
do) eres tu quien debe saber mejor que nadie 
si tu futuro va a estar en esto o no. jAnimo y 
adelante con las siguientes escenas! 





Carlos Monterde Escudero es otro recien llegado al mundo de 
POV que auna la pasion por la infograffa con el gusto por la pro- 
gramacion. Carlos nos envfa varias escenas-experimentos donde un 
objeto magico -el Cupisferio- suele ser el punto central. Carlos bus- 
ca colaboradores interesados en realizar videojuegos (leed su carta 
en el foro) y se confiesa asombrado del nivel de realismo que per- 
mite conseguir POV. En cuanto a los problemas que mencionas, pa- 
ra conseguir sombras de bordes difusos utiliza areas de luz. Esto 
generara sombras mas reales aunque, te aviso, lo pagaras caro en 
tiempo de render. En cuanto al control de la iluminacion, la senten- 
cia scale puede ser empleada para cambiar el tamafio de los objetos a los que se ha asignado una fuente de luz , lo cual no es tu case Pa- 
ra controlar la iluminacion procura emplear pocas fuentes y limftate a cambiar el valor rgb de las mismas o su position. De todos modos 
has logrado una atmosfera muy resultona tanto en Cupsfer.gif como en puerta.gif. t 




Carlos Pastor Mendez es otro nuevo pov-adepto al que agra- 
dezco de corazon que haya decidido apoyar a mis soldaditos en 
la inminente batalla que han de librar contra los orcos. Tranqui- 
lo pov-colega, es cierto que nuestro bando tiene una ligera des- 
ventaja en cuanto a variedad de armamento pero no olvides que 
casi todo el material de los orcos se basa en catapultas mientras 
que nosotros disponemos de canones (jJe!). Ademas es posible 
que antes de la batalla se incluya alguna cosilla extra para vapu- 
lear a esos malolientes hijos de Gorko y Morko. 

En cuanto a tu carro, la idea me parece excelente aunque, no 
te ofendas, su acabado actual recuerda bastante a la manufactura 
snotling: Los misiles son demasiado grandes (y ademas no estan 
permitidos por la convention Orco-humana) y la forma del ca- 
non recuerda a la de un trabuco. Por lo demis la forma general es 
bastante simpatica. jBienvenido a las filas humanas! 
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Giovanni Ststini es un aficionado a la construction de ma- 
quetas de aviones que ultimamente ha decidido entrar en el 
campo del modelismo virtual. Giovanni nos envia este estupen- 
do "Macchi MC202" creado principalmente con Caligari, pro- 
grama para el que pide un mayor espacio en Rendermania (tomo nota). Giovanni tambien 
pregunta por algun foro de news dedicado al tema del modelismo virtual o por alguna di- 
rection de internet dedicada a este asunto. ^Puede alguien dar algun dato sobre esto? En 
cuanto al metodo de construction, Giovanni utilizo un escaner para obtener los perfiles 
del avion. Luego, estos perfiles fueron depurados con Coreldraw antes de grabar las co- 
rrespondientes planullas Dxf que se emplearian despues. Las piezas fueron montadas con 
Caligari y 3D Studio y las texturas fueron creadas con Corel Photo Paint, utilizando co- 
mo planullas imagenes generadas con las vistas del avion. A pesar de tus notas (excesi- 
vamente rigurosas) sobre las carencias del avion, este nos ha parecido fabuloso. 

I'ahlo, un programador de C++ nos remite las siguientes preguntas: 
l)^Hay alguna tool o libreria para manejar imagenes de POV desde C++? 

2) ^,Se pueden programar juegos en 3d en el lenguaje de POV? 

3) ^Hay algun libro que explique las prestaciones del lenguaje de POV? 
Supongo que no te estas refiriendo a funciones para manejar los archivos de imagen 

generados por POV desde C++, sino a funciones para manipular el universo 3d de 
POV desde C++. Existen libren'as para leer y manipular archivos graficos de diversos 
formatos desde C++, pero no resulta posible controlar POV desde C++. El lenguaje de 
POV es un lenguaje "escenico", esto es, se trata de un lenguaje disenado para describir 
modelos y universos 3d. Es cierto que ultimamente -desde la version 3.0- ha empeza- 
do a desdibujarse la frontera entre el lenguaje de POV y cualquier verdadero lenguaje 
de programacion. Asi, POV ya admite bucles, ifs, while, rand, etc, pero sigue presen- 
tando muchas limitaciones con respecto a los lenguajes convencionales. Ademas POV 
emplea la tecnica del trazado de rayos para representar las imagenes descritas por los 
ficheros escenicos con lo cual no resulta posible programar un juego con el ya que pue- 
des necesitar horas o dias para generar cada frame. En cuanto a la documentation, pue- 
des echar mano al "Raytracing II" de Anaya (que no trata las sentencias de "programa- 
cion" de POV puesto que solo cubre la version 2.0) o bien puedes leer los numeros y 
1 de Rendermania. No hay por ahora otras alternativas, salvo leerse el manual. 

Mucfaos lectures nos han solicitado documentation sobre el formato asc de 3D 
Studio. Como de momenta no pensamos tratar este tema os remitimos al Web de 
Viewpoint donde encontrareis documentation sobre este y muchos otros formatos 3d. 
No olvideis que este tipo de documentation suele estar escrita por usuarios que se han 
estrujado los sesos para obtener la information y no por los disenadores de los pro- 
gramas. Por esta razon la information suele no ser fiable o completa al 100%. 



Anuncioy propuesta 
de Rendermania 




